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1. Introduction 


This document is a guide to the use of the OpenSSL FIPS software object module, a software 
component intended for use with the OpenSSL product. It is a companion document to the OpenSSL 
FIPS 140-2 Security Policy document submitted to NIST as part of the FIPS 140-2 validation 
process. It is intended as a technical reference for developers using, and system administrators 
installing, the OpenSSL FIPS software, for use in risk assessment reviews by security auditors, and 
as a summary and overview for program managers. It is intended as a guide for annotation and more 
detailed explanation of the Security Policy, and not as a replacement. In the event of a perceived 
conflict or inconsistency between this document and the Security Policy the latter document is 
authoritative as only it has been reviewed and approved by the Cryptographic Module Validation 
Program (CMVP), a joint U.S. - Canadian program for the validation of cryptographic products 


(http://csrc.nist.gov/cryptval/) 


Familiarity with the OpenSSL distribution and library API (Application Programming Interface) is 
assumed. This document is not a tutorial on the use of OpenSSL and it only covers issues specific to 
the FIPS 140-2 validation. For more information on the use of OpenSSL in general see the many 
other sources of information such as http://openssl.org/docs/ and Reference 4. 


The Security Policy document (Reference 1) is available online at the NIST Cryptographic Module 
Validation website, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733. 


For more information on OpenSSL FIPS please visit http://www.oss-institute.org/, For more 
information on the OpenSSL project see http://openssl.org/. For more information on NIST and the 
cryptographic module validation program, please visit http://csrc.nist.gov/cryptval/. 
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2. Background 


For the purposes of FIPS 140-2 validation the OpenSSL FIPS Object Module v1.1.1 is defined as a 
specific discrete unit of binary object code (the “FIPS Object Module”) generated from a specific set 
and revision level of source files embedded within a source distribution. These platform portable 
source files are compiled to create this object code in an isolated and separated form that is used to 
provide a cryptographic API (Application Programming Interface) to external applications. The term 
FIPS object module elsewhere in this document refers to this OpenSSL FIPS Object Module object 
code. 


The FIPS object module provides an API for invocation of FIPS approved cryptographic functions 
from calling applications, and is designed for use in conjunction with standard OpenSSL 0.9.7 
distributions beginning with 0.9.7m. These recent full OpenSSL source distributions support the 
original non-FIPS API as well as a FIPS mode in which the FIPS approved algorithms are 
implemented by the FIPS object module and non-FIPS approved algorithms other than DH are 
disabled by default. These non-validated algorithms include, but are not limited to, Blowfish, 
CAST, IDEA, RC-family, and non-SHA message digest and other algorithms. 


The FIPS object module was designed and implemented to meet FIPS 140-2 requirements. As such, 
there are no special steps required to ensure FIPS 140-2 compliant operation of the FIPS object 
module, other than building, loading, and initializing the FIPS approved and HMAC-SHA-1 digest 
verified source code. This process of generating the application executable object from source code 
is the same for all platforms’ and is documented in detail in sections 4 and 5 of this document. 


The FIPS object module provides confidentiality, integrity and message digest services. The FIPS 
object module natively supports the following algorithms: DES’, Triple DES, AES, RSA (for digital 
signatures), DH, DSA, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and HMAC-SHA-1, 
HMAC-SHA-224, HMAC-SHA_ 256, HMAC-SHA-384, HMAC-SHA-512. The FIPS object 
module performs ANSI X9.31 compliant pseudo-random number generation. 


2.1 Terminology 
During the course of the OpenSSL validation it became clear that there was a significant disparity in 
terminology between the OpenSSL developers and cryptographers on one hand, and the CMVP and 


FIPS 140-2 specialists on the other hand. In this section some of these distinctions are discussed. 


Approved Mode 


‘By definition, for all platforms to which the validation can be extended. Per the requirements of the Security Policy, any 
change to the documented build process renders the result non-FIPS approved 

*Transitional phase only — DES is valid only until May 19, 2007. Note DES is provided for backward compatibility with 
legacy applications and should not be used for new development. 
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The FIPS 140-2 Approved Mode of Operation is the operation of the FIPS object module when all 
requirements of the Security Policy have been met and the software has successfully performed the 
power-up and self test operation (invocation of the FIPS_mode_set () function call). In this 
document this Approved Mode is referred to simply as FIPS mode. 


Crypto Officer 


System administrator. The FIPS 140-2 Crypto Officer is the person having the responsibility and 
access privileges to install, configure, and initialize the cryptographic software. 


HMAC-SHA-1 digest 


A HMAC-SHA-1 digest of a file using a specific HMAC key (the ASCII string 
“etaonrishdlcupfm”). Such digests are referred to in this document as “digests” or 
“fingerprints”. The digests are used for integrity checking to verify that the software in question has 
not been modified or corrupted from the form originally used as the basis of the FIPS 140-2 
validation. 


Note that the PGP or GPG signatures traditionally used to check the integrity of open source 
software distributions are not a component of any of the FIPS 140-2 integrity checks. 


Module 


The concept of the cryptographic module is an important one for FIPS 140-2, and is discussed in 
detail in §2.2. 


Conceptually the Module is the binary object code and data in the FIPS object module for a running 
process. This binary object as it resides in memory is verified by the FIPS integrity test. 


Working backwards from the software as resident in memory for a process takes us to the executable 
program file from which the process was created, then to the FIPS object module used to link the 
program file, and finally to the original source files used to create the FIPS object module. Each of 
those stages can be thought of as related variations or antecedents of the Module, and the integrity of 
each needs to be verified to assure the integrity of the Module. 


2.2 The FIPS Module and Integrity Test 


The FIPS object module is generated in binary file form, with an embedded pre-calculated HMAC- 
SHA-1 digest calculated over the module’ as it is loaded into application address space. The Module 
integrity check consists of recalculating that digest from the memory areas and comparing it to the 


*Specifically, the text and read-only data segments which constitute the initialized components of the module. 
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embedded value which necessarily resides in an area not included in the calculated digest*. This “in- 
core hashing” integrity test is designed to be both executable format independent and fail-safe. 


For this scenario the Module is the text and data segments as mapped into memory for the running 
application. 


The term Module is also used, less accurately, to designate the antecedent of that memory, the FIPS 
object module file residing on disk. 


The FIPS object module is generated from source code, so the integrity of that source must also be 
verified. The single runtime digest check typical of pre-built binary files is replaced by a chain of 
digest checks in order to validate that the running code was in fact generated from the original source 
code. As before the term Module properly designates the text and data segments mapped into 
memory, but is also more loosely used to reference several levels of antecedents. These levels are 
discussed below. 


2.3 The FIPS Integrity Test 


The FIPS 140-2 standard requires an integrity test of the Module to verify its integrity at 
initialization. In addition to the obvious requirement that the integrity test validate that the FIPS 
object module code and data have not changed, two additional implicit requirements for the integrity 
test were identified during the validation process. 


2.3.1 Requirement for Exclusive Integrity Test 


An integrity test that is merely guaranteed to fail if any of the cryptographic module software 
changes is not sufficient. It is also necessary that the integrity test not fail if the cryptographic 
module software is not directly corrupted, even though the application referencing the cryptographic 
module may be damaged with unpredictable consequences for the correct functioning of that 
application. Another way of looking at this is that application failures are out of scope of the 
integrity test, and the CMVP wanted assurances that changes to application software not affect the 
cryptographic module integrity test. 


This requirement is met with an in-core integrity test that carefully excludes any extraneous object 
code from the digest calculation and verification. 


‘Tf the digest value resided in the data area included in the calculation of that digest, the calculated value of the digest 
would itself be an input into that calculation. 

“This assurance was given by showing during testing that corruption of code or data outside of the memory area 
containing the FIPS object module did not result in an integrity test failure. 
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2.3.2 Requirement for Fixed Object Code Order 


The relative order of all object code components within the module must be fixed and invariant. The 
usual linking process does not care about the relative order of individual object modules, e.g. both 


gcc -o runfile alpha.o beta.o gamma.o 
and 
gcc -o runfile beta.o alpha.o gamma.o 


produce functionally identical executable files. Likewise, the order of object modules in a static link 
library is irrelevant: 


ar r libxxx.a alpha.o beta.o gamma.o 
and 
ar r libxxx.a beta.o alpha.o gamma.o 


produce interchangeable link libraries, and a given application may not incorporate all of the object 
modules contained with the link library when resolving references. For our FIPS 140 validation we 
are required to prevent any such omission or rearrangement of the Module object modules during the 
application creation process. We satisfy this requirement by compiling all the source code into a 
single monolithic object module: 


ld -r -o fipscanister.o fips_start.o ... fips_end.o 


with all the object modules between the fips_start.o and fips_end.o modules that define the low 
and high boundaries of a monolithic object module. All subsequent reference to this monolithic 
object module will preserve the relative order, and presence, of the original object code components. 


2.4 The File Integrity Chain 


The single integrity check of a validated pre-built binary executable is replaced by a chain of 
integrity checks beginning with the source files used for the CMVP validation testing. Note that 
while this chain of checks is more complex, it provides much more visibility for independent 
verification. In the case of validated pre-built binary executables neither the FIPS 140-2 CMVP test 
lab nor the end user has an independent means of directly verifying that the vendor supplied software 
is actually derived from the validated code. With the FIPS object module the prospective user can 
independently verify that the runtime executable does indeed directly derive from the same source 
that was the basis of the validation. 


2.4.1 Source File (Build Time) Integrity 


“Build time” is when the FIPS object module is created from the OpenSSL FIPS source distribution, 
in accordance with the Security Policy. 
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The first file integrity check occurs at build time when the HMAC-SHA-1 digest of the distribution 
file is calculated and compared to the stored value published in the Security Policy (Appendix B). 


Because they reside in this specific distribution and cannot be modified these source files in this 
distribution file are referred to as sequestered files. 


Note that a means to calculate the HMAC-SHA-1 digest is required in order to perform this integrity 
check. A “bootstrap” standalone HMAC-SHA-1 utility, fips_standalone_shal, is included 
in the distribution. This utility is generated first before the sequestered files are compiled in order to 
perform the integrity check. Appendix C gives an example of an equivalent utility. 


2.4.2 Object Module (Link Time) Integrity 


“Link time” is when the application is linked with the previously built and installed FIPS object 
module to generate an executable program. 


The link time integrity check occurs when the FIPS object module is used to create an application 
executable object (binary executable or shared library). The digest stored in the installed file 
fipscontainer.o.shal must match the digest calculated for the fipscontainer.o file. 


The build process described in the Security Policy results in the creation of an object module, 
fipscontainer.o, anda matching digest file, fipscontainer.o.shal. This FIPS object 
module contains the object code corresponding to the sequestered source files (object code for FIPS 
specific functions such as FIPS mode set () and for the algorithm implementations). 


2.4.3 Application Executable Object (Run Time) Integrity 


Application “run time” occurs when the previously built and installed application program is 
invoked. Unlike the previous step this invocation is usually performed repeatedly. 


The runtime integrity check occurs when the application attempts to enable FIPS mode via the 
FIPS_mode_set () function call. The digest embedded within the object code from 
fipscontainer.o must match the digest calculated for the memory mapped text and data areas. 


2.5 Relationship to the OpenSSL API 


The FIPS object module is designed for use with the OpenSSL API. Applications linked with the 
FIPS object module and with the separate OpenSSL libraries can use both the FIPS validated 
cryptographic functions of the FIPS object module and the high level functions of OpenSSL. 
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First, some important definitions to avoid confusion. The FIPS object module is the special 
monolithic object module built from the special source distribution identified in the Security Policy. 
It is not the same as the OpenSSL product or any specific official OpenSSL distribution release. 


A version of the OpenSSL product that is suitable for reference by an application along with the 
FIPS object module is a FIPS compatible OpenSSL. 


When the FIPS object module and a FIPS compatible OpenSSL are separately built and installed on 
a system, the combination is referred to as a FIPS capable OpenSSL. 


Summary of definitions 


The FIPS object module is the FIPS 140-2 validated entity described in the Security Policy 


A FIPS compatible OpenSSL is a version of the OpenSSL product that is designed for compatibility with the 
FIPS object module API 


A FIPS capable OpenSSL is the combination of the separately installed FIPS object module along with a 
FIPS compatible OpenSSL. 


The OpenSSL libraries, when built from a standard OpenSSL distribution with the “fips” 
configuration option for use with the FIPS object module, will contain the usual non-FIPS algorithms 
and non-cryptographic supporting functions, and the non-FIPS algorithm disabling restrictions. 


Note the object modules comprising the FIPS object module could easily be incorporated directly in 
the OpenSSL libcrypto.a library, but for the fact that such a combination is specifically 
forbidden by FIPS 140-2 and the CMVP*. 


Various non-FIPS algorithms such as Blowfish, IDEA, CAST, MD2, etc. will be included in the 
OpenSSL libraries (depending on the . /config options specified in addition to fips). For 
applications that do not care about FIPS 140-2 the resulting libraries are drop-in compatible with the 
libraries generated without the fips option (a deliberate design decision to encourage wider 
availability and use of FIPS 140-2 validated algorithms). The converse is not true; a non-FIPS 
compatible OpenSSL library cannot be substituted for the FIPS compatible library for an application 


SActually, to encourage use of fipscanister.o even in non-FIPS mode application, a copy is incorporated into 
libcrypto.a, but special care is taken to preclude its usage in FIPS enabled applications. The fipsld utility provided 
in the FIPS compatible OpenSSL distributions prevents that usage as follows. In static link context that is achieved by 
referencing the official fipscanister.o first on the command line., and in dynamic link context by temporarily 
removing it from libcrypto.a. This removal is necessary because dynamic linking is commonly accompanied by 
whole-archive, which would force both copies of fipscanister.o into the shared library. Note the integrity 
check is designed as a failsafe precaution in the event of link errors --even if two copies are included into the application 
in error, the integrity check will prevent the use of one copy for the integrity test and the other for the actual 
implementation of cryptography. In other words, if both the official fipscanister.o and the unvalidated version 
that is embedded in 1ibcrypto.a both end up in an executable binary, and if FIPS_mode_set () returns success, 
the unvalidated copy will not be used for cryptography. 
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using FIPS mode because the FIPS specific function calls, in particular FIPS_mode_set (), will 
not be present. 


Applications that do wish to use FIPS mode must call the FIPS_mode_set () function, and after 
the runtime FIPS mode initialization the non-FIPS algorithms are disabled by default. 


In this sense the combination of the FIPS object module and the usual OpenSSL libraries constitutes 
a “FIPS capable API”, capable of being used for either FIPS mode operation or for conventional 
non-FIPS purposes as before. 


2.6 FIPS Mode of Operation 


The FIPS object module together with a compatible version of the OpenSSL product can be used in 
the generation of both FIPS mode and conventional applications. The enabling of runtime FIPS 
mode is optionally enabled by a function call. 


Only one initialization call, FIPS_mode_set (), is required to operate the FIPS object module in 
a FIPS 140-2 Approved mode, referred to herein as "FIPS mode". When the FIPS object module is 
in FIPS mode all security functions and cryptographic algorithms are performed in Approved mode. 
Use of the FIPS mode set () function call is described in §5. 


A power-up self-test is performed automatically by the FIPS_mode_set () call, or optionally at 
any time by the FIPS_selftest () call (see Appendix D). If any power-up self-test fails the 
internal global error flag FIPS_selftest_fail is set and subsequently tested to prevent 
invocation of any cryptographic function calls. 


The internal global flag FIPS_mode is set to FALSE indicating non-FIPS mode by default. The 
FIPS_mode_set () function verifies the integrity of the runtime executable using a HMAC- 
SHA-1 digest computed at build time. If the digests match the power-up self-test is then performed. 
If the power-up self-test is successful FIPS_mode_set () sets the FIPS_mode flag to TRUE 
and the FIPS object module is in FIPS mode. 


By design, the OpenSSL API attempts to disable non-FIPS algorithms, when in FIPS mode, at the 
EVP level and via most low level function calls. Failure to check the 

return code from low level functions could result in unexpected behavior. Note also that sufficiently 
creative or unusual use of the API may still allow the use of non-FIPS algorithms. The non-FIPS 
algorithm disabling is intended as a aid to the developer in preventing the accidental use of non-FIPS 
algorithms in FIPS mode, and not as an absolute guarantee. 


OpenSSL provides a mechanism, the "ENGINE" component, for interfacing with external 
cryptographic devices such as accelerator cards. This mechanism is not disabled in FIPS mode. In 
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general, if a FIPS validated cryptographic device is used with OpenSSL in FIPS mode so that all 
cryptographic operations are performed either by the device or the FIPS object module, then the 
result is still FIPS compliant. In general, the OpenSSL FIPS 140-2 validation still holds true in the 
case that other separately FIPS 140-2 validated hardware or software modules are utilized in 
conjunction with the OpenSSL FIPS validated cryptographic module. 


However, if any cryptographic operations are performed by a non-FIPS validated device the result is 
not FIPS compliant. The application developer has the responsibility of not enabling the use of non- 
FIPS validated devices via OpenSSL ENGINE support. 
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3. Compatible Platforms 


The FIPS object module was built from source and tested on specific hardware/software 
environments (See the Security Policy) . The FIPS object module maintains vendor affirmed FIPS 
140-2 compliance on other operating systems provided that the conditions described in Section 4 of 
the Security Policy apply. 


The FIPS object module is designed to run on a very wide range of hardware and software platforms. 
Any such computing platform that meets the conditions in the Security Policy can be used to host a 
FIPS 140-2 validated FIPS object module provided that module is generated in accordance with the 
Security Policy. At the time the OpenSSL FIPS Object Module v 1.1.1 was developed all Unix®’-like 
environments supported by the full OpenSSL distribution were also supported by the FIPS validated 
source files included in the FIPS object module. However, successful compilation of the FIPS object 
module for all such platforms was not verified. If any platform specific compilation errors occur that 
can only be corrected by modification of the FIPS distribution files (see Appendix B of the Security 
Policy) then the FIPS object module will not be validated for that platform Note also that future 
releases of OpenSSL may support additional platforms requiring new or changed source from that of 
the current FIPS source distribution, in which case use of OpenSSL with the FIPS object module 
will not be validated for those new platforms. 


By default, the FIPS object module software utilizes assembly language optimizations for some 
supported platforms. Currently assembler language code residing within the cryptographic module 
boundary is used only for the x86/Intel®® ELF machine architecture. The FIPS object module build 
process will automatically select and include these assembly routines by default when performed on 
a x86 platform. This assembly language code was included in the validation testing and hence a 
FIPS object module built using the x86/Intel® assembly language routines will be a FIPS 140-2 
validated FIPS object module. 


3.1 Build Environment Requirements 


The platform portability of the FIPS object module source code is contingent on several basic 
assumptions about the build environment: 


1. The environment is “Unix*-like” with a make command and a 1d command with a “-r” (or 
“—i”) option. 


Creation of the monolithic FIPS object module fipscanister.o requires a linker 
capable of merging several object modules into one. This requirement is known to be a 
problem with VMS and some older versions of LD . EXE under Windows”. 


"UNIX is a registered trademark of The Open Group 
SIntel is a registered trademark of the Intel Corporation 
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2. The compiler is required to place variables declared with the const qualifier in a read-only 
segment. This behavior is true of almost all modern compilers. If the compiler fails to do so 
the condition will be detected at run-time and the in-core hashing integrity check will fail. 
See Appendix F.1 for an example of one such compiler. 


3. The application executable can be loaded and executed on the build platform (i.e., no cross 
compilation), due to the need to load and execute the application executable after the first 
pass link with the pre-main code (see fips_premain.c). Ina cross-compilation 
environment this program invocation may not be possible at all, or if possible may result in 
an in-core hash value that is invalid for the target platform. 


The major issue with cross-compilation is that it is highly non-portable. In some cases cross- 
compilation may work; for example where the code is position independent and Gnu binutils 
are used then in principle support for in-core hashing could probably be implemented in 
future versions of the FIPS object module; however such support will need to be verified for 
every such platform. 


3.2 Known Supported Platforms 


The generation of a monolithic object module and the in-core hashing integrity test have been 
verified to work with both static and shared builds on the following platforms (note the ./config 

shared option is forbidden by the terms of the validation when building a FIPS validated 
module, but was verified in the course of development). Note a successful build of the FIPS module 
may be possible on other platforms; only the following were explicitly tested as of the date this 
document was written: 


Linux®’ on x86, x86 64, ia64 

SPARC® Solaris®”, both 32 and 64 bit ABIs 

x86 Solaris® on 32 and 64 bit ABIs 

IRIX@" 6.5, n32, and 64-bit ABIs 

Tru64@” 

HP-UX®", 32 and 64 bit PA-RISC®, 32 and 64 bit ia64 
Mac OS X®" on PowerPC®” 


“Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. 

SPARC and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other 
countries. 

"TRIX is a trademark of Silicon Graphics, Inc. 

”Tru64 is a registered trademark of Compaq Computer Corporation. 

HP-UX is a registered trademark of Hewlett-Packard Company. 

“Mac OS X is a registered trademark of Apple Computer, Inc. 

PowerPC is a trademarks of International Business Machines Corporation in the United States, other countries, or both. 
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e Windows®" with Cygwin®” and Mingw 
e OpenBSDe” and FreeBSD@' on x86 


Among the platforms known to not be supported are VMS” and Windows CE. 


Windows is a registered trademark of Microsoft Corporation in the United States and other countries. 
“Cygwin is a registered trademark of Red Hat, Inc. 

BOpenBSD is a registered trademark of Theo de Raadt. 

FreeBSD is a registered trademark of the FreeBSD Foundation. 

°VMS is a registered trademark of Digital Equipment Corporation. 
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4. Generating the FIPS Object Module 


This section describes the creation of a FIPS object module for subsequent use by an application. 


4.1 Delivery of Source Code 


The OpenSSL FIPS object module software is available only in source format. The OpenSSL FIPS 
Object Module v1.1.1 source code was originally designed to be contained as a subset of the standard 
OpenSSL distributions beginning with version 0.9.7j. However, at the very end of the validation 
process the decision was made to define the source code as consisting of an entire OpenSSL 
distribution, and the terms of the validation require that the FIPS object module be built from that 
one specific distribution. That specific distribution was taken from the FIPS development branch 
which was a mid-release version of OpenSSL after 0.9.7i and before 0.9.7j, and it does contain some 
bugs since fixed in the 0.9.7j branch. This specific distribution can be found at 


http://www.openssl.org/source/openssl-fips-1.1.1.tar.gz, or from one of the many mirrors maintained 


worldwide. 


The OpenSSL FIPS object module software was delivered to the FIPS 140-2 testing laboratory in 
source form as this complete OpenSSL distribution, and was built by them using the standard build 
procedure as described below and in Appendix B. 


Note this downloaded file is untrusted for any purpose until verified as described in 84.1.2, and 
untrusted for the purposes of building a FIPS object module until verified as described in 84.1.3. 


4.1.1 Creation of a FIPS Object Module from Other Source Code 


Some OpenSSL distributions other than the specific distribution used for the validation can be used 
to build a fipscanister.o object using undocumented build-time options. The reader is reminded 
that any such object code cannot be used or represented as FIPS 140-2 validated. The Security 
Policy document is very clear on that point. 


4.1.2 Verifying Integrity of Distribution 


The integrity and authenticity of the complete OpenSSL distribution should be validated manually 
with the PGP signatures”! published by the OpenSSL Team with the distributions 
(ftp://ftp.openssl.org/source/) to guard against a corrupted source distribution. Note this check is 
separate and distinct from the specific FIPS 140-2 source file integrity check (84.1.3). 


The PGP signatures are contained in the file 


“Note this PGP/GPG signature check is not related to any of the FIPS integrity checks! 
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openssl-fips-1.1.1.tar.gz.asc 


This digital signature of the distribution file can be verified against the OpenSSL PGP public key by 
using the PGP or GPG applications (GPG can be obtained free of charge from 
http://www.gnupg.org/)*. This validation consists of confirming that the distribution was signed by 
a known trusted key as identified in Appendix A, “OpenSSL Distribution Signing Keys”. 


First, find out which key was used to sign the distribution. Any of several different valid keys may 
have been be used for this purpose. The "hexadecimal key id", an identifier used for locating keys 
on the keystore servers, is displayed when attempting to verify the distribution. If the signing key is 
not already in your keyring the hexadecimal key id of the unknown key will still be displayed: 


$ gpg openssl-0.9.7c.tar.gz.asc 

gpg: Signature made Tue Sep 30 09:00:37 2003 using RSA key ID 49A563D9 
gpg: Can't check signature: public key not found 

$ 


Example 4.1.2a - Find Id of Signing Key 


In this example the key id is 49A563D9. Next see if this key id belongs to one of the OpenSSL 
core team members authorized to sign distributions. The authorized keys are listed in Appendix A. 


Note that some older versions of gpg will not display the key id of an unknown public key; either 
upgrade to a newer version or load all of the authorized keys. 


If the hexadecimal key id matches one of the known valid OpenSSL core team keys then download 
and import the key. 


PGP keys can be downloaded interactively from a keyserver web interface or directly by the pgp or 
gpg commands. 


The hexadecimal key id of the team member key (for example, the search string "0x49A563D9" 
can be used to download the OpenSSL PGP key from a public keyserver (http://www.keyserver.net/, 
http://pgp.mit.edu, or others). Keys can be downloaded interactively to an intermediate file or 
directly by the pgp or gpg program. 


$ gpg --import markcox.key 

gpg: key 49A563D9: public key "Mark Cox <mjc@redhat.com>" imported 
gpg: Total number processed: 1 

gpg: imported: 1 (RSA: 1) 
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Example 4.1.2b - Importing a Key from a Downloaded file 


Once downloaded to an intermediate file, markcox.key in this example, the key can be imported with 
the command: 


These examples assume the pgp or gpg software is installed. The key may also be imported directly 
into your keyring: 


$ gpg --keyserver pgp.mit.edu --recv-key 49a563d9 

gpg: key 49A563D9: public key "Mark Cox <mjc@redhat.com>" imported 
gpg: Total number processed: 1 

gpg: imported: 1 (RSA: 1) 


Example 4.1.2c - PGP Key Import 


Note that at this point we have not yet established that the key is authentic or that the distribution 
was signed with that key; a key that might be authentic has been obtained in a form where it can be 
utilized for further validation. 


To verify that the distribution file was signed by the imported key use the pgp or gpg command 


with the signature file as the argument, with the distribution file also present in the same directory: 
Example 4.1.2d - PGP File Signature Verification 


$ gpg /work/build/openssl/openssl-0.9.7c.tar.gz.asc 
gpg: Signature made Tue Sep 30 09:00:37 2003 using RSA key ID 49A563D9 
gpg: Good signature from "Mark Cox <mjc@redhat.com>" 


gpg: aka "Mark Cox <mark@awe.com>" 

gpg: aka "Mark Cox <mark@c2.net>" 

gpg: aka "Mark Cox <mcox@c2.net>" 

gpg: aka "Mark Cox <mark@ukweb.com>" 

gpg: aka "Mark Cox <mjc@apache.org>" 

gpg: WARNING: This key is not certified with a trusted signature! 

gpg: There is no indication that the signature belongs to the owner. 


Primary key fingerprint: 7B 79 19 FA 71 6B 87 25 OE 77 21 E5 52 D9 83 BF 
$ 


In this example the validity of the file signature with respect to the key is verified, i.e. the target file 
openssl-fips-1.1.1.tar.gz was signed by the key with id 49A563D9. The warning message in 
this example is noting the fact that the key is not already part of the "web of trust", a relational 
ranking system based on manually assigned confidence levels. Instead of relying on the web of trust 
which will differ from one user to another the key should be matched directly to a list of known valid 
keys. 
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For this final step establish that the signing key, now known to have signed the distribution, is in fact 
authentic. Confirm that the key fingerprint of the key which signed the distribution, 7B 79 19 FA 
71 6B 87 25 OE 77 21 E5 52 D9 83 BF inthis example, is one of the valid OpenSSL core 
team keys listed in Appendix A, “OpenSSL Distribution Signing Keys”. 


At this point the signature of the distribution has been verified as belonging to the signing key, and 
the authenticity of the signing key has been verified against a reference (this document) downloaded 
from the NIST web site. 


4.1.3 Verifying Integrity of the Full Distribution for the FIPS Object Module 


A separate source file integrity check is required to meet the requirements of FIPS 140-2. 


The HMAC-SHA-1 digest of the distribution file is published in Appendix B of the Security Policy. 


The Security Policy can be found at NIST, http://csrc.nist.gov/cryptval/140-1/140sp/140sp733.pdf. 
This digest should be calculated and compared against the published value, as in: 


$ env OPENSSL_FIPS=1 openssl shal -hmac etaonrishdlcupfm openssl-fips-1.1.1.tar.gz 


where the openssl command is from a recent version of OpenSSL that supports the -hmac 
option”. If you don't have the openssl command yet it will be generated by the build process. 


4.2 Building and Installing the FIPS Object Module with OpenSSL 
(Unix/Linux) 


Due to significant differences in the two basic operating system families, Unix*/Linux® and 
Microsoft® Windows® platforms are discussed separately. Instructions for Windows® are given in 
section 4.3. 


4.2.1 Building the FIPS Object Module from Source 


Next build the FIPS object module from source. The FIPS 140-2 validation specific code is 
incorporated into the generated FIPS object module when the fips configuration option is 
specified. Per the conditions of the FIPS 140-2 validation only one configuration command may be 
used: 


./config fips 


The OPENSSL_FIPS=1 environment variable will enable FIPS mode for an openssl command built from a FIPS 
capable OpenSSL distribution. 
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The specification of any other options on the command line, such as 
./config fips shared 


is specifically not permitted. Note that in the case of the “shared” option this means that position 
independent code cannot be specified and so the generated FIPS object module cannot (for most 
platforms) be included in a shared library”. 


Note that as a condition of the FIPS 140-2 validation no other user specified configuration options 
may be specified. The “shared” option will have to be covered in a future validation. 


Then: 


make 


to generate the FIPS Object Module file fipscanister.o, the digest for the FIPS Object 
Module file, fipscanister.o.shal, and the source file used to generate the embedded digest, 
fips_premain.c. The fipscanister.o, fipscanister.o.shal, and 

fips premain.c files are intermediate files (i.e., used in the generation of an application but not 
referenced by that application at runtime). The object code in the fipscanister.o file is 
incorporated into the runtime executable application at the time the binary executable is generated. 


This should also be obvious, but modifications to any of the intermediate files generated by the 
“./config fips” or “make” commands are not permitted. If the original distribution is 
modified, or if anything than those three specified commands are used, or if any intermediate files 
are modified, the result is not FIPS validated. 


4.2.2 Installing and Protecting the FIPS Object Module 


The system administrator should install the generated fipscanister.o, 
fipscanister.o.shal, and fips_premain..c files in a location protected by the host 
operating system security features. These protections should allow write access only to authorized 
system administrators (FIPS 140-2 Crypto Officers) and read access only to authorized users. 


For Unix® based or Linux® systems this protection usually takes the form of root ownership and 
permissions of 0755 or less for those files and all parent directories. For Microsoft® Windows® 
based systems this protection can be provided by ACLs limiting write access to the administrator 
group. When all system users are not authorized users the world (public) read and execute 
permissions should be removed from these files. 


*4Tf not for the FIPS validation prohibition, or most but not all platforms the “shared” option could safely be chosen 
regardless of the intended use. See Appendix H for one known exception. 
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The usual 
make install 


will install the fipscanister.o, fipscanister.o.shal, fips_premain.c, and 
fips_premain.c.shal files in the target location (typically /usr/local/lib/ for Unix® 
based or Linux® systems.) with the appropriate permissions to satisfy the security requirement. 
These four files constitute the validated FIPS object module, the (many) other files also installed by 
this command are not validated. 


Note that fipscanister.o can either be statically linked into an application binary executable, 
or statically linked into a shared library”. 


4.2.3 Building a FIPS Capable OpenSSL 


At this point a full OpenSSL library has been installed. However, the special distribution required to 
generate the validated FIPS object module does not correspond exactly to any official OpenSSL 
releases. Once the validated FIPS object module has been generated the other OpenSSL components 
can be replaced with components from a different OpenSSL distributions. Any 0.9.7 releases 0.9.7m 
and later can be used for this purpose. The commands 


./config fips <...other options...> 
make <...options...> 
make install 


will install the new OpenSSL without overwriting the validated FIPS object module files. 


The combination of the validated FIPS object module plus an OpenSSL distribution built in this way 
is referred to as a FIPS capable OpenSSL, as it can be used either as a drop-in replacement for a non- 
FIPS OpenSSL or for use in generating FIPS mode applications. 


Note that a standard OpenSSL distribution built for use with the FIPS object module must have the 
./config fips option specified. Other configuration options may be specified in addition to 
fips, but omission of the fips option will cause errors when using the OpenSSL libraries with the 
FIPS object module. 


4.3 Building and Installing the FIPS Object Module with OpenSSL 
(Windows) 


3If and only if, that is, the “./config fips” command alone, without the “shared” option, generates object code suitable for 
inclusion in a shared library. 
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The usual OpenSSL build procedure for Windows”, per the INSTALL.W32 file, uses commands of 
the form 


perl Configure VC-WIN32 


ms/do_nasm -or- ms/do_ms 
nmake -f ms/ntdll.mak 


The Security Policy for this validation specifically requires use of the commands 

./config fips 

make 

make install 
as the FIPS 140-2 validation was targeted for Unix®/Linux® style platforms, but thanks to some 
creative work by Steve Henson the following procedure can be used under Microsoft® Windows® to 


build the FIPS object module in compliance with the conditions of the Security Policy. 


The build process for Windows® also proceeds in two separate stages. The first compiles and installs 
the FIPS module from a Unix® like build environment and only needs to be performed once. 


The second stage uses VC++ to link OpenSSL 0.9.7m or later against the installed FIPS module, to 
obtain the complete FIPS capable OpenSSL Both static and shared libraries are supported. 


4.3.1 Building the FIPS Object Module from Source 


1. Install the MingW and MSYS packages. Probably the easiest way to do this is to run the two 


Windows® installer programs from http://sourceforge.net/projects/mingw and www.mingw.org 
respectively. The current versions are called MinGW-5.1.3.exe andMSYS-1.0.10.exe. 
Run the MINGW installer *first*. 


2. Start the MSYS shell by selecting it from the start menu or double clicking the desktop icon. 
From the shell type: 


gcc version 
and verify that the version is at least 3.4.2. 


3. Extract the OpenSSL FIPS tarball with the following command: 


tar xvzf d:/some/path/openssl-fips-1.1.1l.tar.gz 
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Where the path is wherever you downloaded the tarball. 
Note: the msys shell uses slashes, “/”, as path separators not backslashes, “\”. 
4. Change to the source directory with the command: 
cd openssl 
5. Compile and install the sources using the standard build procedure: 


./config fips 
make 


Note that the warning: 


Can't open fips_aes_data: No such file or directory at 
../../util/mklink.pl line 62. 


is normal and can be ignored. 


4.3.2 Installing and Protecting the FIPS Object Module 


6. As with the Unix®/Linux® platforms, just enter 
make install 
7. Extract additional object modules with: 
cd /usr/local/ssl/lib 
ar xv ‘gcc -print-libgcc-file-name` _chkstk.o _udivdi3.o N 
_umoddi3.o0o 
8. Check that the libraries have been installed properly. This can be done with: 


ls 


which should produce the following output: 


_chkstk.o _umoddi3.o fips_premain.c.shal 
fipscanister.o.shal Jlibssl.a 

_udivdi3.o0 fips premain.c fipscanister.o libcrypto.a 
pkgconfig 
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9. Obtain the Windows” path of the installed FIPS module with the command: 
pwd —W 

which will print the Windows® path of the directory, for example: 
C:/msys/1.0/local/ssl/lib 

Make a note of this path. 

10. Exit the MSYS shell by typing Ctrl-D. Copy the files: 
_chkstk.o 


_umoddi3.o 
_udivdi3.o 


fips_premain.c.shal 
fipscanister.o.shal 
fips_premain.c 
fipscanister.o 


from the previously noted FIPS directory to any convenient location and set their permissions 
according to the Security Policy, so the files are writable only by the system administrator. 


11. (Optional) Since these steps only have to be performed once, the MingW and MSYS installation 


and the entire OpenSSL FIPS module sources can be uninstalled and discarded. 


4.3.3 Building a FIPS Capable OpenSSL 


The final stage is VC++ compilation of a standard OpenSSL distribution to be referenced in 
conjunction with the previously built and installed FIPS object module. 


Download an OpenSSL 0.9.7 distribution, 0.9.7m or later. Follow the standard Windows” build 
procedure except that instead of the command: 


perl Configure VC-WIN32 
do: 


perl Configure VC-WIN32 fips --with-fipslibdir=c:\fips\path 
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where "c: \ fips \path" is wherever the FIPS module from the first stage was installed. Static 
and shared library builds are supported. 


This command is followed by the usual 

ms\do_nasm 
or 

ms \do_ms 
and 

nmake -f ms\ntdll.mak 
to build the shared libraries only, or 

nmake -f ms\nt.mak 
to build the OpenSSL static libraries. The standard OpenSSL build with the fips option will use a 
base address for 1ibeay32.dl1 of 0xFB00000 by default. This value was chosen because it is 
unlikely to conflict with other dynamically loaded libraries. In the event of a clash which relocates 
libeay32.d11 the integrity check will fail with the error 


FIPS R FINGERPRINT DOES NOT MATCH NONPIC RELATED 


A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with 
an alternative base address specified with the --with-baseaddr- option. 


Note that the developer can identify which DLLs are relocated with the Process Explorer utility from 
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx”’. 


The resulting FIPS capable OpenSSL can be used for shared or static linking. The shared library 
build (when ms \ntd11.mak is used as the Makefile) links fipscanister.o into 
libeay32.d11 using fipslink.pl in accordance with the requirements of the Security 
Policy. 


There is a related utility, depends .exe, bundled with some Microsoft products and available for 
free download from http://www.dependencywalker.com/ or several locations on the Microsoft web 
site. This utility shows which DLLs an application is linked with, but not how those DLLs are 
mapped into process address space at run-time. In the current context we are more interested in 
where in the address space those DLLs are mapped. 
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5. Creating Applications Which Reference the FIPS Object 
Module 


Only minor modifications are needed to adapt most applications that currently use OpenSSL for 
cryptography to use the FIPS capable OpenSSL with the FIPS object module. This checklist 
summarizes the modifications which are covered in more detail in the following discussion: 


a Use the FIPS object module for all cryptography 

a Initialize FIPS mode with FIPS_mode_set() 

a Generate application executable object with embedded FIPS 
object module digest 

a Protect critical security parameters 


Figure 4 - Application Checklist 


Appendix C contains a simple but complete sample application utilizing the FIPS object module with 
OpenSSL as described in this section. 


5.1 Exclusive Use of the FIPS Object Module for Cryptography 


In order for the referencing application to claim FIPS 140-2 validation all cryptographic functions 
utilized by the application must be provided exclusively by the FIPS object module. The OpenSSL 
API used in conjunction with the FIPS object module in FIPS mode is designed to automatically 
disable all non-FIPS cryptographic algorithms. 


5.2 FIPS Mode Initialization 


Somewhere very early in the execution of the application FIPS mode must be enabled. This should 
be done by invocation of the FIPS_mode_set () function call, either directly or indirectly as in 
these following examples. 


Note that it is permitted to not enable FIPS mode, in which case OpenSSL should function as it 
always has. The application will not, of course, be operating in validated mode. 


Option 1: Direct call to FIPS mode set() 
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#ifdef OPENSSL_FIPS 

if (options.no_fips <= 0) 

{ 

if (!FIPS_mode_set (1) ) 

{ 

ERR load crypto strings(); 
ERR print errors fpi(stderr); 
exit (1); 


} 
else 
fprintf(stderr,"*** IN FIPS MODE ***\n"); 
} 
#endif 


E 


Example 5.2a - Direct Invocation of FIPS mode set() 


Option 2: Indirect call via OPENSSL config() 


As of OpenSSL version 0.9.7n the OPENSSL config () call can be used to enable FIPS mode via the 
standard openss1.conf configuration file: 


OPENSSL (config ( XXXX conf ) 


#ifdef OPENSSL FIPS 
if (FIPS mode ()) 
{ 


fprintf(stderr,"*** IN FIPS MODE ***\n"); 


} 
#endif 


Example 5.2b — Indirect Invocation of FIPS mode set() 


The call to OPENSSL config( XXXX conf ) will check the system default OpenSSL configuration 
file for a section XXXX conf. If section XXXX conf is not found then the section defaults to 
openssl_conf. The resulting section is checked for a alg_section specification naming a section 
that can contain an optional “fips_mode = yes” statement. 
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# Default section 
XXXX_conf = XXXX_options 


[ XXXX_options ] 
alg_section = algs 


[ algs ] 
fips_mode = yes 


Example 5.2c — Sample openssl.conf File 


Note that OPENSSL config() has no return code. If a configuration error occurs it will write to 
STDERR and forcibly exit the application. Applications that want finer control can call the 
underlying functions such as CONF_modules_load_file() directly. 


5.3 Generate Application Executable Object 


Note that applications interfacing with the FIPS object module are outside of the cryptographic 
boundary. 


When statically linking” the application with the FIPS object module two steps are necessary: 


1. 


The HMAG-SHA-1 digest of the FIPS object module file must be calculated and verified against 
the installed digest to ensure the integrity of the FIPS object module. 


A HMAC-SHA1 digest of the FIPS object module code and read-only data must be generated 
and embedded in the application executable object for use by the FIPS_mode_set() function 
at runtime initialization. 


5.3.1 Linking under Unix/Linux 


“For those platforms where fipscanister.o can be incorporated in shared code, if it has been incorporated in a 
shared library then subsequent dynamic linking of an application to that shared library is done the usual way and these 
steps are irrelevant. 
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The OpenSSL distribution contains a utility, Fipsld, which both performs the check of the FIPS 
object module and generates the new HMAC-SHA-1 digest for the application executable. The 
fipsld utility has been designed to act as a front end for the actual compilation and linking 
operations in order to ease the task of modifying an existing software project to incorporate the FIPS 
object module. It can be used to create either binary executables or shared libraries. 


The fipsld command requires that the CC and/or FIPSLD_CC environment variables be set, 
with the latter taking precedence. These variables allow a typical Makefile to be used without 
modification by specifying a command of the form 


make CC=fipsld FIPSLD_CC=gcc 


where fips1d is invoked by make in lieu of the original compiler and linker (gcc in this 
example), and in turn invokes that compiler where appropriate. 


This type of command line macro overloading will work for many smaller software projects. The 
makefile can also be modified to achieve the same macro substitutions. Depending on the form of 
the Makefile this substitution may be as simple as defining FIPSLD_CC to reference the actual C 
compiler and redefining the CC macro to reference fips1d: 


FIPSLD CC = $(CC) 
CC = fipsld 


<application>: $(OBJS) 
$(CC) $(SCFLAGS) -o $@ $(OBJS) $(LIBCRYPTO) 


Setting CC=fipsld is appropriate when the link rules rely on $ (CC) instead of 1d to produce the 
executable images, but in some cases it may be desirable or necessary to not redefine the $(CC) 
macro variable. A typical makefile rule referencing fips1d directly for the link step would look 
something like”: 


OPENSSLDIR 
FIPSMODULE 


/usr/local/ssl 
$ (OPENSSLDIR) /lib/fipscanister.o 


<application>: $(OBJS) S$(FIPSMODULE) 
env FIPSLD_CC=$(CC) fipsld $(CFLAGS) -o $@ S(OBJS) \ 


The use of env is actually redundant in a Makefile context, but is specified here to give a command line also valid for 
non-Bourne shells. 
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$ (LIBS) $(LIBCRYPTO) 


Even though the £ips1d command name implies use as a replacement for the 1d command, it also 
invokes the C compiler between the two link stages, hence fipsi1d can also replace $ (CC) in rules 
producing .o object files, replacing both compilation and linking steps for the entire Makefile, i.e.: 


<application>.o: <application>.c 
$(CC) $(CFLAGS) -c <application>.c 


<application>: $(OBJS) 
ld -o $@ $(OBJS) $(LIBCRYPTO) 


becomes 


<application>: <application>.c 
env FIPSLD_CC=$(CC) fipsld $(CFLAGS) -o $@ S@.c \ 
$ (LIBCRYPTO) 


Larger software projects are likely to prefer to modify only the Makefile rule(s) linking the 
application itself, leaving other Makefile rules intact. For these more complicated Makefiles the 
individual rules can be modified to substitute £ips1d for just the relevant compilation linking steps. 


The fipsld command is designed to locate fipscanister.o automatically. It will verify that 
the HMAC-SHA-1 digest in file fipscanister.o.shal matches the digest generated from 
fipscanister.o, and will then create the file <application> containing the object code 
from fipscanister.o, and embedded within that the digest calculated from the object code and 
data in fipscanister.o. 


At runtime the FIPS mode set () function compares the embedded HMAG-SHA-1 digest with 


a digest generated from the text and data areas. This digest is the final link in the chain of validation 
from the original source to the application executable object file. 


5.3.2 Linking under Windows 


For a shared library application just linking with the DLL is sufficient. Linking an application with 
the static libraries involves a bit more work, and can be complicated by the fact that GUI based tools 
are often used for such linking. 


For the Windows® environment a perl script fipslink .p1 is provided which performs a function 
similar to fipsid for Unix®/Linux®. Several environment variables need to be set: 


FIPS LINK is the linker name, normally “link” 
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FIPS CC is the C compiler name, normally “c1” 
FIPS_CC_ARGS isa string of C compiler arguments for compiling fips_premain.c 


PREMAIN_DSO_EXE should be set to the path to fips_premain_dso.exe if a DLL is 
being linked (can be omitted otherwise) 


PREMAIN_SHA1_EXE is the full path to fips_standalone_shal.exe 
FIPS TARGET is the path of the target executable or DLL file 
FIPSLIB_D is the path to the directory containing the installed FIPS module 


When these variables are specified fipslink .p1 can be called in the same way as the standard 
linker. It will automatically check the hashes, link the target, generate the target in-core hash, and 
link a second time to embed the hash in the target file. 


The static library Makefile ms \nt .mak in the OpenSSL distribution gives an example of the usage 
of fipslink.pl. 


5.4 Application Implementation Recommendations 


This section describes additional steps not strictly required for FIPS 140-2 validation but 
recommended as good practice. 


Provide an Indication of FIPS Mode 


Security and risk assessment auditors will want to verify that an application utilizing cryptography is 
using FIPS 140-2 validated software in a FIPS compliant mode. Many such applications will 
superficially appear to function the same whether built with a non-FIPS OpenSSL, when built with 
the FIPS object module and running in non-FIPS mode, and when built with the FIPS object module 
and running in FIPS mode. 


As an aid to such reviews the application designer should provide a readily visible indication that the 
application has initialized the FIPS object module to FIPS mode, after a successful return from the 
FIPS_mode_set() API call. The indication can take the form of a tty or stdout message, a 
syslog entry, or an addition to a protocol greeting banner. For example a SSH server could print a 
protocol banner of the form: 


SSH-2.0-OpenSSH_3.7.1p2 FIPS 
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to provide an easily referenced indication that the server was properly initialized to FIPS mode. 
Graceful Avoidance of Non-FIPS Algorithms 


Many applications allow end user and/or system administrator configurable specification of 
cryptographic algorithms. The OpenSSL API used with the FIPS object module in FIPS mode is 
designed to return error conditions when an attempt is made to use a non-FIPS algorithm via the 
OpenSSL API. These errors may result in unexpected failure of the application, including fatal 
assert errors for algorithm functions calls lacking a testable return code. However, there is no 
guarantee that the OpenSSL API will always return an error condition in every possible permutation 
or sequence of API calls that might invoke code relating to non-FIPS algorithms. In any case, it is 
the responsibility of the application programmer to avoid the use of non-FIPS algorithms. 
Unexpected run-time errors can be avoided if the cipher suites or other algorithm selection options 
are defaulted to FIPS approved algorithms, and if warning or error messages are generated for any 
end user selection of non-FIPS algorithms. 


5.5 Documentation and Record-keeping Recommendations 


The supplier or developer of a product based on the FIPS Object Module cannot claim that the 
product itself is FIPS 140-2 validated under certificate #733. Instead a statement similar to the 
following is recommended: 


Product XXXX uses an embedded FIPS 140-2-validated cryptographic module (Certificate 
#733) running on a YYYY platform per FIPS 140-2 Implementation Guidance section G.5 
guidelines. 


where XXXX is the product name (“Cryptomagical Enfabulator v3.1@“) and YYYY is the host 
operating system (“Solaris 10”). 


While not strictly required by the Security Policy or FIPS 140-2, a written record documenting 
compliance with the Security Policy would be a prudent precaution for any party generating and 
using or distributing an application that will be subject to FIPS 140-2 compliance requirements. This 
record should document the following: 


For the FIPS Object Module generation: 


1. Where the openssl-fips-1.1.1.tar.gz distribution file was obtained from, and how the HMAC 
SHA-1 digest of that file was verified per Appendix B of the Security Policy. 

2. The host platform on which the fipscanister.o, fipscanister.o.sha1, fips_premain.c, and 
fips_premain.c.sha1 files were generated. This platform identification at a minimum should 
note the processor architecture (“x86”, “PA-RISC”,...), the operating system (“Solaris 10”, 
“Windows XP”,...), and the compiler (“gcc 3.4.3”,...). 
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3. An assertion that the fipscanister.o module was generated with the three commands 


/config fips 

make 

make install 
and specifically that no other build-time options were specified. 
A record of the HMAC SHA-1 digest of the fipscanister.o (the contents of the 
fipscanister.o.sha1 file). That digest identifies this specific FIPS Object Module; if you 
immediately build another module it will have a different digest and is a different FIPS 
Object Module. 
An assertion that the contents of the distribution file were not manually modified in any way 
at any time during the build process. 


For the application in which the FIPS Object Module is embedded: 


1. 


2. 


5.6 


A record of the HMAG SHA-1 digest of the fipscanister.o that was embedded in the 
application. 

An assertion that the application does not utilize any cryptographic implementations other 
that those provided by the FIPS Object Module or contained in the FIPS capable OpenSSL 
0.9.7m+ libraries (where non-FIPS algorithms are disabled in FIPS mode). 

A description of how the application clearly indicates when FIPS mode is enabled (assuming 
that FIPS mode is a runtime selectable option). Note that the application must call 
FIPS_mode_set(), whether that call is triggered by runtime options or not. 


When is a Separate FIPS 140-2 Validation Required? 


When a decision is made on whether a particular IT solution is FIPS 140-2 compliant multiple 
factors need to be taken into account, including the FIPS Pub 140-2 standard, FIPS 140-2 Derived 
Test Requirements, CMVP FAQ and Implementation Guidance. The ultimate authority in this 
process belongs to the CMVP. The CMVP provides its current interpretations and guidelines as to 
the interpretation of the FIPS 140-2 standard and the conformance testing/validation process on its 


public web site http://csrc.nist.gov/cryptval/. 


In particular, the only official document known to us which discusses use of embedded 
cryptographic modules is the official CMVP FAQ available at 
http://csrc.nist.gov/cryptval/140-1/CMVPFAQ.pdf. This FAQ (Frequently Asked Questions 
document) discusses incorporation of another vendor's cryptographic modules in a subsection of 
Section 2.2.1 entitled "Can I incorporate another vendor's validated cryptographic module". In 
particular, the following is specified: 


"Yes. A cryptographic module that has already been issued a FIPS 140-1 or FIPS 140-2 
validation certificate may be incorporated or embedded into another product. The new 
product may reference the FIPS 140-1 or FIPS 140-2 validated cryptographic module so 
long as the new product does not alter the original validated cryptographic module. A 
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product which uses an embedded validated cryptographic module cannot claim itself to be 
validated; only that it utilizes an embedded validated cryptographic module. There is no 
assurance that a product is correctly utilizing an embedded validated cryptographic module - 
this is outside the scope of the FIPS 140-1 or FIPS 140-2 validation." 


Note that the CMVP FAQ does specify that a FIPS 140-1/2 validated module may be incorporated 
into another product. It then specifies that making a decision on whether a product is correctly 
utilizing an embedded module is outside of the scope of the FIPS 140-1 or FIPS 140-2 validation. 


A subsection of Section 2.1 of the CMVP FAQ entitled "A vendor is selling me a crypto solution - 
what should I ask?" states: 


"Verify with the vendor that the application or product that is being offered is either a 
validated cryptographic module itself (e.g. VPN, SmartCard, etc) or the application or 
product uses an embedded validated cryptographic module (toolkit, etc). Ask the vendor to 
supply a signed letter stating their application, product or module is a validated module or 
incorporates a validated module, the module provides all the cryptographic services in the 
solution, and reference the modules validation certificate number." 


It is specified that the module provides "all the cryptographic services in the solution". It is not 
specified that the module provides "all the security-relevant services in the solution". A typical IT 
product may provide a variety of services, both cryptographic and non-cryptographic. A network 
protocol such as SSH or TLS provides both cryptographic services such as encryption and network 
services such as transmission of data packets, packet fragmentation, etc. 


The FIPS 140-2 standard is focused on the cryptography. There are many generically security 
relevant functionalities such as anti-virus protection, firewalling, IPS/IDS and others which are not 
currently covered by the FIPS 140-2 standard. An anti-virus solution which uses a cryptographic 
module for its operations can satisfy requirements of the FIPS 140-2 by delegating its cryptographic 
functions to an embedded FIPS 140-2 validated module. Including the entire anti-virus solution in 
the FIPS 140-2 validation would hardly improve the overall security since FIPS 140-2 does not 
currently have requirements in the field of anti-virus protection. In a similar fashion, the FIPS 140-2 
standard does not currently have requirements related to network vulnerabilities or denial of service 
attacks. 


Validated modules typically provide algorithm implementations only, no network functionality such 
as IPSec, SSH, TLS etc. This does not, for example, prevent Microsoft Windows from providing 
IPSec/IKE and TLS/SSL functionality. Therefore, for example, an OpenSSH based product properly 
using the OpenSSl1 FIPS Object Module would not differ from Microsoft using its Microsoft Kernel 
Mode Crypto Provider in Microsoft IPSec/IKE client which is shipped with every copy of Windows. 
If an application product delegates all cryptographic services to a validated module the entire product 
will be FIPS compliant. 
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A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11 protocol family may 
provide a complex variety of services. Some aspects of such services may have a cryptographic 
nature and utilize Approved or “allowed for use” cryptographic algorithms, such as encryption, 
decryption, signatures, hashes, message digests and others. Other services provided by a network 
protocol may be of non-cryptographic nature, such as packet routing, packet assembly/disassembly, 
defragmentation, radio and link layer communications, firewalling, network address translation, 
address resolution, quality of service, re-transmission and others. While the ultimate verdict for a 
particular solution belongs to the CMVP, it is generically logical to assume that non-cryptographic 
services of a particular network protocol or a set of protocols may be implemented outside of a 
validated cryptographic module. This is also logical having in mind that in many cases non- 
cryptographic services of a particular protocol may be delegated to other devices in the IT solution. 
For instance, in some wireless LAN access systems an implementation of the 802.11 protocol set is 
provided jointly by a wireless access switch and a wireless access point, where the wireless access 
point may provide non-cryptographic services of the 802.11 protocol set such as radio transmissions, 
frequency and signal strength control, initial wireless client association and others. Another widely 
used example is a web server offloading cryptographic functionality of the HTTPS/TLS protocol to a 
FIPS 140-2 validated cryptographic accelerator card (many such cards are available on the market). 


In addition to consulting the written CMVP guidance, it is then also important to consider industry- 
wide interpretation patterns and precedents in this field. After performing a review of the FIPS 
140-2 validated products list http://csrc.nist.gov/cryptval/140-1/140val-all.htm one may conclude 
that implementing non-cryptographic services of a particular network protocol outside of a validated 
cryptographic module can in many cases be considered as an industry trend. There are multiple 
examples which illustrate such a trend. For illustration purposes only we can take a look at the 
example of the Microsoft Kernel Module 


http://csrc.nist.gov/cryptval/140-1/140sp/140sp241.pdf 


Note that there are many other modules which follow a similar trend, this module is just one example 
out of many. The analysis here is generic, applies to a large number of validated modules, and is not 
intended to make any specific statements as to the validation of this particular module. 


As specified by the vendor, the Kernel Module is used by the vendor implementation of the 
IPSec/IKE protocol 


http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true 


In particular it is stated that 


"Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the FIPS-140-1 or FIPS 
140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module to encrypt the traffic 
packet data and file contents respectively if configured appropriately with the selections of 
FIPS compliant algorithms." 


Page 39 of 61 
FIPS 140-2 User Guide - September 27, 2007 


OpenSSL FIPS Object Module 
FIPS 140-2 User Guide 


A review of the Kernel Module Security Policy then shows that the module's services are specified 
as services performing cryptographic algorithms supported by IPSec/IKE(such as 
encryption/decryption and key agreement) and not as providing a full IPSec/IKE protocol 
implementation. This could again serve as an illustration of the fact that non-cryptographic services 
of a particular protocol are in many cases implemented outside of a cryptographic module. A similar 
analysis could be performed for other protocols specified in 


http://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx?mfr=true 


such as S/MIME (used in Outlook), TLS (used in Explorer), Remote Desktop Protocol and 
Encrypting File System. Other examples can be discussed by analyzing the list of historically 
validated products http://csrc.nist.gov/cryptval/140-1/140val-all.htm. In general the vendor of a 
product based on the OpenSSL FIPS Object Module should be able to find an existing validated 
module, and similar products claiming validation by virtue of that module, for one of several large 
well-known IT companies. 


In conclusion, both the historical perspective and the current CMVP guidance point to a possibility 
of non-cryptographic services in an IT solution being implemented outside of a validated 
cryptographic module. We are not aware of any CMVP regulations explicitly denying use of 
embedded validated cryptographic modules to satisfy the requirements of FIPS 140-2 statement, 
provided that the set of conditions specified in the CMVP FAQ and other relevant documentation is 
satisfied. With this in mind, the ultimate decision for a particular product/protocol belongs to the 
CMVP and the analysis presented here can serve for discussion purposes only. 


The main job of a FIPS 140-2 testing lab is to consistently apply current regulations including the 
FIPS 140-2 standard, the Derived Test Requirements and the Implementation Guidance. Testing 
labs can have suggestions for further improvements which could be communicated to the CMVP and 
potentially incorporated in the future versions of the standard or in the implementation guidance. For 
the current version of the standard a testing lab needs to apply the current regulations impartially to 
all vendors. If in the future the CMVP decides to introduce a simple and inexpensive program for 
validating compliance of IT solutions with embedded FIPS 140-2 modules it might be a reasonable 
idea. For now, as explained in the CMVP FAQ, such validation is not available. 


Since the CMVP does not have a formal program for validation of IT solutions with embedded FIPS 
140-2 modules, the question is how is the actual compliance/non-compliance determined. In practice 
the compliance is determined by the federal agency/buyer selecting the solution. During the process 
the customer may contact the CMVP, testing labs or security experts for an opinion. In many cases, 
though, the buyers make such decisions independently. Here it should be noted that FIPS 140-2 is 
only a baseline and each federal agency may establish its own requirements exceeding the 
requirements of FIPS 140-2. In the particular example of network protocols federal agencies 
generally do accept networking products (IPSec/TLS/SSH etc.) with embedded FIPS 140-2 validated 
cryptographic software modules or hardware cards as FIPS 140-2 compliant. 
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For those vendors desiring a “sanity check” of the compliance status of their OpenSSL FIPS Object 
Module based product, OSSI can perform a review and provide an opinion letter stating whether, 
based on information provided by the vendor, that product appears to OSSI to satisfy the 
requirements of the OpenSSL FIPS Object Module Security Policy. This opinion letter can include 
a review by one or more CMVP test labs and/or a OpenSSL team member as appropriate. This 
opinion letter clearly states that only the CMVP can provide an authoritative ruling on FIPS 140-2 
compliance. 
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Future Plans 


The current validated FIPS object module has a number of limitations, among them: 


1. 


The shared build-time configuration option (or any other option for that matter) cannot be 
used when building the FIPS object module, so for most platforms the FIPS object module 
cannot be incorporated into shared code. The CMVP would have required separate algorithm 
testing for both the “./config fips”and“./config fips shared” cases, 
doubling the test lab workload at a time when all funding had already been exhausted. 


The FIPS object module is not compatible with OpenSSL versions 0.9.8+, due to extensive 
changes in OpenSSL that introduce compatibility issues with the FIPS object module API 
which cannot, of course, be modified to match. 


The creation of the FIPS object module under Microsoft Windows® is awkward. The original 
validation was Unix®-centric by design, as the co-sponsors were interested in Unix® support 
only. Thanks to significant efforts by Steve Henson and others a method for building the 
FIPS object module in compliance with the conditions of the validation has been devised, but 
that method differs from the usual OpenSSL build process under Windows®. 


The source file distribution for the FIPS object module includes a great deal of superfluous 
source and data. The requirement to sequester the entire OpenSSL development branch was 
only recognized at the very end of the validation process, as all the attention to that point had 
been focused on the isolation of the object code. If we had appreciated that requirement 
earlier on then a more streamlined stand-alone source distribution of just the source files 
relevant to the FIPS object module generation would have been prepared; as it was this 
realization came to late to invest the necessary time and resources to that effort. 


Not all FIPS compliant cryptographic algorithms are validated (ECC, for example). An 
algorithm test involves coding a test driver (dsa/fips dsatest.c, 

hmac/fips hmactest.c, etc. in the ./fips-1 .0/ subdirectory) to process input test 
vectors in a format described in a standards document. Most of these were relatively 
straightforward, if tedious, to code, though a few required considerable trial-and-error 
experimentation to interpret. 


The first OpenSSL FIPS validation was a pioneer effort that confronted may uncertainties in the 
validation process, with limited resources. Now that the validation has been awarded and the 
requirements for a source code validation are better understood these limitations can be addressed in 
future validations. 
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Any such future validation will have one large fixed cost, the CMVP testing laboratory fee, plus 
whatever costs are associated with the specific software development items. For that reason the 
more financial co-sponsors are involved in a given validation, the lower the cost to each. 


Any interested parties willing to consider co-sponsoring a future OpenSSL FIPS 140-2 or 140-3 
validation effort should contact 


John Weathersby 601-427-0152 office 

Executive Director 601-818-7161 cell 

Open Source Software Institute 601-427-0156 fax 

Administrative Office jmw@oss-institute.org 
P.O. BOX 547 http://oss-institute.org/ 


Oxford, MS 38655 


for information on current plans and the opportunities for participation. 
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The algorithm certificates: 


RSA http://csrc.nist.gov/cryptval/dss/rsaval.html#177 

DSA http://csrc.nist.gov/cryptval/dss/dsaval.htm#175 
3DES http://csrc.nist.gov/cryptval/des/tripledesval.html#451 
AES http://csrc.nist.gov/cryptval/aes/aesval.html#420 
HMAC http://csrc.nist.gov/cryptval/mac/hmacval.html#194 
SHA-1,2 http://csrc.nist.gov/cryptval/shs/shaval.htm#490 

RNG http://csrc.nist.gov/cryptval/mg/rmgval.html#216 
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Appendix A OpenSSL Distribution Signing Keys 


In order to be considered FIPS 140-2 validated the FIPS object module must be derived from an 
OpenSSL distribution signed by one of these authorized keys, as shown by the value in the 
Fingerprint row. 


The procedure for verifying that a source distribution was signed by one of these keys is described in 
detail in 84.1.2. 


Note the fingerprint formats are slightly different for the two different types of keys (RSA and 
DSA). 


OpenSSL Core Team PGP Keys 


Key Id Team member 


49A563D9 | Mark Cox <mark@awe.com> 
Fingerprint 7B 79 19 FA 71 6B 87 25 OE 77 21 E5 52 D9 83 BF 


26BB437D | Ralf S. Engelschall <rse@engelschall.com> 
Fingerprint 00 C9 21 8E D1 AB 70 37 DD 67 A2 3A OA 6F 8D A5 


F295C759 | Dr Stephen Henson <shenson@drh-consultancy.co.uk> 
Fingerprint DO 5D 8C 61 6E 27 E6 60 41 EC B1 B8 D5 7E E5 97 


9C58A66D | Lutz Janicke <Lutz.Jaenicke@aet.TU-Cottbus.DE> 
Fingerprint 13 DO B8 9D 37 30 C3 ED AC 9C 24 7D 45 8C 17 67 


2118CF83 | Ben Laurie <ben@cryptix.org> 
Fingerprint 7656 55DE 62E3 96FF 2587 EB6C 4F6D E156 2118 CF83 


E06D2CB1 | Richard Levitte <levitte@lp.se> 
Fingerprint 35 3E 6C 9E 8C 97 85 24 BD 9F D1 9E 8F 75 23 6B 


5A6A9B85 | Bodo Moeller <2004@bmoeller.de> 
Fingerprint C7 AC 7E AD 56 6A 65 EC F6 16 66 83 7E 86 68 28 
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Appendix B Application Test Procedure 


Instructions for building OpenSSL and performing the FIPS 140-2 and related algorithm tests on a 
Unix® or Linux® based platform are given here. These instructions are primarily of interest to the 
FIPS 140-2 testing laboratory performing the validation testing, or anyone wishing to verify that the 
executable library generates generates the same output for the algorithm tests performed by the 
testing laboratory. 


B.1 Building the Software 


1. Copy the OpenSSL distribution (openssl-fips-1.1.1.tar.gz) to a directory on the test system. 
Approximately 80Mb free space is needed. 


2. Perform the standard build. Use of a Script file or comparable means of capturing the output 
is highly recommended. 


gunzip -c openssl-fips-1.1.1.tar.gz | tar xf - 
cd openssl 

./config fips 

make 

make test 


This step builds the runtime executables and performs the standard integrity test. A large amount 
of output is generated. If an error occurs processing will be aborted. 


B.2 Algorithm Tests 


If desired the algorithm tests run by the CMVP lab during validation testing can be reproduced. 
Note there is no practical reason for end users or application developers to run these tests, this 
discussion is included for reference purposes to illustrate the algorithm testing performed by the 
CMVP test lab. Note this step requires a large directory tree of input test data files; several sets of 
input and response values can be found at http://www.oss-institute.org/FIPS 733/testvectors/ 


or http://www.openssl.org/docs/fips/. 
3. Add the subtree of test data to the distribution workarea: 


cd fips-1.0 
gunzip -c testvectors.rsp.XXX.tar.gz | tar xf - 


4. Run the FIPS 140 algorithm tests: 
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cd fips-1.0 
make fips_test 


This step runs the tests specific to the FIPS mode. Again a large amount of output will be 
generated. If an error occurs processing will be aborted. 


5. The many (approximately 275) generated * . r sp files will be found in the . /fips—1.0/ 
directory tree: 


ls -l ./openssl-N.N.N/fips/testvectors/*/rsp/*.rsp 
6. The tree of * . rsp files can be extracted for comparison with another tree: 


find testvectors -name '*.rsp' | cpio -oc > rspl.cpio 


cd /tmp 

mkdir rspl rsp2 

cd rspl; cpio -ic < rspl.cpio 

cd ../rsp2; cpio -ic < rsp2.cpio 
diff -r . ../rsp1l 


If the only differences are the commented date-time labels then the trees match: 


diff -r ./testvectors/aes/rsp/CBCGFSbox128.rsp N 
../rspl/testvectors/aes/rsp/CBCGFSbox128.rsp 

6c6 

< # Thu Mar 4 11:05:36 2004 

> # Fri Feb 20 12:21:24 2004 

diff -r ./testvectors/aes/rsp/CBCGFSbox192.rsp \ 
../rspl/testvectors/aes/rsp/CBCGFSbox192.rsp 

6c6 

< # Thu Mar 4 11:05:36 2004 


> # Fri Feb 20 12:21:24 2004 


Note that several reference sets of * . rsp files are available on request from OSSI, but are not 
included in the OpenSSL distributions. 
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B.3 FIPS 140-2 Test 


A test driver program has been provided to demonstrate both successful and failed power-up self- 
tests and the invocation of some basic cryptographic operations. This program was developed during 
the course of the FIPS 140-2 validation as a aid to the test lab evaluators and as such has no real 
value in any other context. This test program, fips_test_suite, can be found in the ./test/ 
subdirectory. 


7. When executed with no argument output similar to the following is produced: 


$ ./fips_test_suite 
FIPS-mode test application 


1. Non-Approved cryptographic operation test... 


a. Included algorithm (D-H)...successful 
2. Automatic power-up self test...successful 
3. AES encryption/decryption...successful 
4. RSA key generation and encryption/decryption...successful 
5. DES-ECB encryption/decryption...successful 
6. DSA key generation and signature validation...successful 
7a. SHA-1 hash...successful 
7b. SHA-256 hash...successful 
7c. SHA-512 hash...successful 
7d. HMAC-SHA-1 hash...successful 
7e. HMAC-SHA-224 hash...successful 
7f. HMAC-SHA-256 hash...successful 
7g. HMAC-SHA-384 hash...successful 
7h. HMAC-SHA-512 hash...successful 


8. Non-Approved cryptographic operation test... 
a. Included algorithm (D-H)...successful as expected 
9. Zero-ization... 
Generated 128 byte RSA private key 
BN key before overwriting: 
8E0CD7345733DA2922DFDA0C8FC7 9F5B7F67567E8391C81FA0A32 98DF1CE0C6A33646A0840F5 
5F098711075F457943FC340719760851E21DB7918A8B0728D4F33F1210FC22A52EF8BB20353F 
98BB3C8C7E2FC5C36B4 9AC2 8E0932568CFC94 8E6F4923F42906BC8B14E4071E8960EF17974C8 
700541241 B4F3BB3D5FO001E45C01 
BN key after overwriting: 
8045F430EAD7D1IADF7E3582517692DC69F 958844C62FDE68DF 62F31A2 6F1F319BDEO4A62DBCB 
B0965B7055BB45B613E428B29F22797884DFC1B51B5 9334 6F 9B9470FB660F 91B8FA487AE469A 
B7FFC23135CF5107FD62D5E355D613462F08D5D5235D62A8 97B398F7089FD911144B3AF33492 
BDOC5B7FB93B43D26CE2 6B60E9DF 
char buffer key before overwriting: 
4850f0a33aedd3af6e477£8302b10968 
char buffer key after overwriting: 
8f££13£1c2311f£716£165e24a5042c47d 
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All tests completed with 0 errors 


$ 


To demonstrate the effect of a corrupted Known Answer Test invoke the fips test suite 
command with one of the arguments aes, des, dsa, rsa, shal, rng. The 
command must be invoked separately with each argument for the KAT test to fail for each 
separate algorithm. Output similar to the following will be produced for each algorithm (aes in 
this example): 


$ ./fips test suite aes 
FIPS-mode test application 


3. AES encryption/decryption with corrupted KAT... 
24557:error:24064064:random number generator:SSLEAY RAND BYTES:PRNG not 
seeded:md rand.c:512:You need to read the OpenSSL FAQ, 
http://www.openssl.org/support/faq. html 
24557:error:2A068065:1ib (42) :FIPS selftest aes:selftest 
failed:fips aes selftest.c:92: 

Power-up self test failed 


$ 
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Appendix C Example OpenSSL Based Application 


This example shows a simple application using OpenSSL cryptography which will qualify as FIPS 
140-2 validated when built and installed in accordance with the procedures in §5. In this application 
all cryptography is provided through the FIPS object module and the FIPS mode initialization is 
performed via the FIPS_mode_set () call. The command generates a HMAC-SHA-1 digest of 
an input stream or a file, using the same arbitrary key as the OpenSSL FIPS Module file integrity 
check: 


$ ./hmac -v hmac.c 

FIPS mode enabled 
8£2c8e4Ff60607613471c11287423f8429b068eb2 
$ 

$ ./hmac < hmac.c 
8£2c8e4F60607613471c11287423f8429b068eb2 
$ 


Note this sample command is functionally equivalent to: 


env OPENSSL_FIPS=1 openssl -hmac etaonrishdlcupfm hmac.c 


The OPENSSL FIPS-1 environment variable enables FIPS mode for a openssl command 
generated from a FIPS capable OpenSSL distribution. 


Makefile 


CC = gcc 

OPENSSLDIR = /usr/local/ssl 

LIBCRYPTO = $ (OPENSSLDIR) /lip/libcrypto.a 
INCLUDES = -I$ (OPENSSLDIR) /include 

CMD = hmac 

OBJS = $(CMD).o 


$ (CMD): $(OBJS) 
FIPSLD_CC=$ (CC) $(OPENSSLDIR)/bin/fipsld -o $(CMD) $(OBJS) \ 
$ (LIBCRYPTO) 


$(OBJS): $(CMD).c 
$(CC) -c $(CMD).c $ (INCLUDES) 


clean: 
rm $ (OBJS) 


Note the line 
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$ (OPENSSLDIR) /fips/fipsld -o $(CMD) $(OBJS) 


the fipscanister.o digest and generating the new embedded digest in the application 
executable object. 


Source File 


/* 


od 


Sample application using FIPS mode OpenSSL. 


This application will qualify as FIPS 140-2 validated when built, 


installed, and utilized as described in the "OpenSSL FIPS 140-2 
Security Policy" manual. 


This command calculates a HMAC-SHA-1 digest of a file or input data 
stream using the same arbitrary hard-coded key as the FIPS 140-2 


source file build-time integrity checks and runtime executable 
file integrity check. 


#include <stdio.h> 
#include <string.h> 
#include <openssl/hmac.h> 


static char label[] = "@(#)FIPS approved SHA1 HMAC"; 


static void dofile(FILE *fp) 


} 


{ 

HMAC_CTX ctx; 

unsigned char hmac_value[EVP_MAX_MD_SIZE]; 
int hmac_len, i; 

char key[16] = "etaonrishdlcupfm"; 

char buf[256]; 


/* Generate digest of input stream */ 

HMAC_Init (&ctx, key, sizeof (key), EVP_shal()); 

while (fgets (buf, sizeof (buf)-1,fp)) { 
HMAC_Update(&ctx, buf, strlen(buf)); 

} 

HMAC_Final(&ctx, hmac value, &hmac len); 

HMAC_cleanup (&ctx) ; 


for(i = 0; i < hmac len; i++) printf("%02x", hmac_value[i]); 
printf("\n"); 
return; 


main(int argc, char *argv[]) 


{ 
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char *opt = NULL; 


int verbose = 0; 

int fipsmode = 1; 
FILE *fp = stdin; 
int i; 


/* Process command line arguments */ 
i.s Os 
while (ti < argc) { 

opt = argv[i]; 


if (!strcemp(opt,"-v")) verbose = 1; 
else if (!strcemp(opt,"-c")) fipsmode = 0; 
else if ('-' == opt[0]) { 


printf ("Usage: %s <filename>\n", argv[0]); 
puts ("Options:"); 

puts ("\t-c\tUse non-FIPS mode"); 

puts ("\t-v\tVerbose output"); 

exit (1); 

} 

else break; 


} 


/* Enter FIPS mode by default */ 
if (fipsmode) { 
if (FIPS_mode_set(1)) { 
verbose && fputs("FIPS mode enabled\n", stderr); 
} 
else { 
ERR load crypto strings(); 
ERR print. errors fpi(stderr); 
exit (1); 


} 


if (i >= argc) { 
dofile(fp); 
} 
else { 
while(i < argc) { 
opt = argv[i]; 


if ((fp = fopen(opt,"r")) == NULL) { 
fprintf (stderr, "Unable to open file \"%Ss\"\n", opt); 
exit (1); 


} 
dofile (fp); 
fclose (fp); 
i++; 
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Appendix D FIPS API Documentation 


D.1 FIPS mode 
NAME 
FIPS mode - NIST FIPS 140-2 Approved mode of operation 
DESCRIPTION 
When built with the fips config option in accordance with some additional 
procedural requirements the OpenSSL FIPS object module can be used to satisfy 
requirements for FIPS 140-2 validated cryptography. 
OVERVIEW 
The OpenSSL FIPS object module must be built with the fips config option. The 
application must call FIPS mode set() to enable FIPS mode. When in FIPS mode only 
the FIPS approved encryption algorithms 
are usable: 
+RSA 
+DSA 
+DES in CBC, (CFB1), CFB8, CFB64, ECB, OFB modes 
+DH 
+AES in CBC, (CFB1), CFB8, CFB128, ECB, OFB modes with 128/192/256 bit keys 
+SHA-1, SHA-2 
+HMAC 
Other non-FIPS approved algorithms such a Blowfish, MD5, IDEA, RC4, etc. are 
disabled in FIPS mode. 
If the FIPS power-up self-test fails subsequent cryptographic operations are disabled 
and the application will have to exit. 
To be considered FIPS 140-2 validated the OpenSSL FIPS object module must use the 
validated version of the FIPS specific OpenSSL source code. 
While most platforms and applications can use the OpenSSL FIPS object module to 
satisfy NIST requirements for FIPS 140-2 validated cryptography there are additional 
additional requirements beyond the call to FIPS mode set(). A more complete discussion 
of the OpenSSL FIPS mode can be found in the OpenSSL FIPS 140-2 Security Policy which 
can be found at http://csrc.nist.gov/cryptval/140-1/140sp/140sp733.pdf. 
Information about FIPS 140 can be found at http://csrc.nist.gov/cryptval/. 
NOTES 


The power-up self-test can take a significant amount of time on slower systems. 
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HISTORY 
FIPS mode support was introduced in version m of OpenSSL. 
SEE ALSO 


FIPS_mode_set(7) 


D.2 FIPS_mode_set(), FIPS selftest() 


NAME 

FIPS mode set, FIPS selftest - perform FIPS power-up self-test 
SYNOPSIS 

#include <openss1/fips/fips.h> 

int FIPS mode set (int ONOFF) 

int FIPS_selftest(void) 
DESCRIPTION 


FIPS_mode_set() enables the FIPS mode of operation for applications 

that have complied with all the provisions of the OpenSSL FIPS 140-2 Security 
Policy. Successful execution of this function call with non-zero ONOFF is the 
only way to enable FIPS mode. After verifying the integrity of the executable 


object code using the stored digest FIPS mode set() performs the power-up self-test. 


When invoked with ONOFF of zero FIPS mode set() exits FIPS mode. 


FIPS selftest() can be called at any time to perform the FIPS power-up self-test. 


If the power-up self-test fails subsequent cryptographic operations 
are disabled. The only possible recovery is a successful re-invocation of 


FIPS mode set() which is unlikely to work unless the original path was incorrect. 


RETURN VALUES 

A return code of 1 indicates success, O failure. 
SEE ALSO 

FIPS_mode(7) 
HISTORY 


FIPS support was introduced in version m of OpenSSL. 


D.3 Error Codes 
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The FIPS_mode_set() call or other function calls in FIPS mode can return any of the following 
errors: 


FIPS R FINGERPRINT DOES NOT MATCH "fingerprint does not match" 
The integrity test has failed. 


FIPS R FINGERPRINT DOES NOT MATCH NONPIC RELOCATED 
“fingerprint does not match, possibly because of non-PIC relocation" 
This Microsoft Windows specific error indicates that there might be a DLL address conflict which needs to be 
addressed by re-basing the offending DLL. 


FIPS_R_FINGERPRINT_DOES_NOT_MATCH_SEGMENT_ALIASING 
“fingerprint does not match, because of invalid segment aliasing" 
This error is returned when a defective compiler has merged .rodata (read-only) and .data (writable) segments. This 
situation effectively degrades the read-only status of constant tables and leaves them without hardware protection, 
thus jeopardizing the FIPS mode of operation. 


FIPS R FIPS MODE ALREADY SET "fips mode already set" 


FIPS_R_FIPS_SELFTEST_FAILED “fips selftest failed" 
An algorithm known answer tests has failed. 


FIPS_R_NON_FIPS_METHOD "non fips method" 
Attempted non FIPS-compliant DSA usage. 


FIPS_R_PAIRWISE_TEST_FAILED “pairwise test failed" 
One or more of the algorithm pairwise consistency tests has failed. 


FIPS_R_SELFTEST_FAILED "selftest failed" 
One or more of the algorithm known answer tests has failed. 


FIPS R UNSUPPORTED PLATFORM “unsupported platform" 
Indicates the validity of the digest test is unknown for the current platform. 
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Appendix E The PRNG and Fork Protection 


FIPS 171 (X9.31) effectively requires a PRNG seed based on the system time only, due to the 
requirement that the initialization vector never repeat. The accepted way to guarantee that the IV 
never repeats is to use a millisecond (or higher) precision system Date-Time (DT) value. 


A truly random number generator will of course (rarely) produce the same value twice. The 
requirement that the implementation guarantee that the IV can never be repeated limits the options 
for generating the seed value. In particular it forbids the usual techniques of folding process specific 
information into the seed for the reseeding child processes after a fork( ) call. The fact that this 
“fork protection” is absent in the FIPS object module PRNG concerns many in the OpenSSL 
developer and user community, and will be the primary obstacle to making the fips configuration 
option a default. 


At present there is no known way to satisfy those concerns and still meet the FIPS 140-2 
requirements for PRNG validation. Hence of all the FIPS mode algorithms only the PRNG is 
functionally different from the original algorithm implementations. 


The issue of child processes reseeding with unique values is discussed in: 


Viega paper “Practical Random Number Generation in Software”, 
http://www.acsac.org/2003/papers/79.pdf. 


Ben Laurie, “On Randomness”, http://www.apache-ssl.org/randomness.pdf. 


Peter Gutmann, “Software Generation of Practically Strong Random Numbers”, 
http://www.usenix.org/publications/library/proceedings/sec98/full_papers/gutmann/gutmann.pdf. 
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Appendix F Platform Specific Issues 


F.1 Compiler placement of read-only data 


The in-core hashing mechanism requires that read-only data be placed in a read-only data segment. 
The FIPS_set_mode () function is designed to detect situation where this requirement is not met. 
One example of this problem is on 32 bit HP-UX PA-RISC when using gcc to generate position 
independent code (-FPIC). At least some versions of gcc do not discriminate read-only data and put 
it [read-only data] into a writable data segment. This problem has been observed with gcc 3.2.3, and 
3.4.2. It effectively voids the embedded digest value and the verification procedure is bound to fail. 


A simple test program will demonstrate the problem. On a 32 bit HP-UX PA-RISC system using 
gcc the commands 


echo "const int i=0;" > a.c 
gcc. =c.a.c 

size a.o 

gcc -c -fPIC a.c 

size a.o 

gcc -v 


generate the output 


8+0++0=8 

0+8+02=8 

Reading specs from /usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2.3/specs 
Configured with: ../gcc-3.2.3/configure --enable-languages=c, c++ --with-gnu-as 
Thread model: single 

gcc version 3.2.3 


On the same 32 bit HP-UX PA-RISC system using the HP C compiler the commands: 


echo "const int i=0;" > a.c 
cc -Ae -c a.c 

cc -Ae HZ -c a.c 

cc -V -Ae -c a.c 


give the result 


4+0+0=4 
4+0+0=4 
cpp.ansi: HP92453-01 B.11.11.32871.GP HP C Preprocessor (ANSI) 
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ccom: HP92453-01 B.11.X.34412-34415.GP HP C Compiler 


The workaround for this bug is to advise users to use the HP C compiler for their 32-bit HP-UX PA- 
RISC applications until/if gcc is fixed. 


F.2 Bugs in Microsoft TLS Implementation 


In FIPS mode the number of available ciphersuites is restricted to those using DES, 3DES, AES, 
SHA-1 and SHA-2, resulting in negotiation of AES, DES, and 3DES in CBC mode with a TLS 
client. At least some versions of the Microsoft SSL/TLS implementation of CBC are unable to 
handle the empty fragments inserted in CBC mode by OpenSSL as a countermeasure for a minor 
security issue. 


A discussion of this security issue can be found at http://www.openssl.org/~bodo/tls-cbc.txt. The 
general consensus of the OpenSSL developers who implemented the FIPS mode is that this 
vulnerability is relatively minor. 


This use of empty fragments can be disabled with the function call 


SSL_CTX_set_options (ctx, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS) 


Note the rudimentary https server provided by the (FIPS compatible) openss! command can be used 
to test for this bug: 


OPENSSL_FIPS=1 openssl s_server -www [-debug] 
Note that TLS is disabled by default for the Microsoft Internet Explorer (go to “Tools” menu, select 
“Internet Options...”, select “Advanced”, scroll top the bottom and enable “Use TLS 1.0”). 


F.3 Solaris and gcc 


There is a known problem with some versions of gcc” on x86 Solaris where a program linked with 
the OpenSSL libcrypto will segfault in " init", 


Every object module consists of segment fractions which are merged by the link-editer. For 
example, .text fractions from all * .o files are concatenated to form the program . text segment. 
Every such fraction is allowed to specify alignment in the resulting image and the link-editer is 


” And with the Sun C compiler also, but OpenSSL currently does not use assembler optimizations with that compiler. 
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expected to align it accordingly. When different fractions specify different alignments the link- 
editer pads the previous fragment until the alignment requirement for the currently processed 
fragment is met. The value used for padding varies by implementation. Solaris 1a uses a value of 
zero, which means that for executable segments machine code is padded with zeros. That means that 
if the processor attempts to interpret that zero padding, it would execute a series of 'add %al, 
(seax)' instructions. Depending on the value in register eax that instruction might work or it 
might incur a segmentation violation. But, even if the instruction does not segfault it can cause 
unpredicted behavior later on. A better choice of padding value would be one which maps into an 
instruction which has no effect on the processor state. In x86 context 0x90 (the NOP machine 
instruction) would be an appropriate value. 


Why is only the . init segment is affected and not .text? Because .text fragments contain either 
complete functions and padding zeros are preceded by flow transfer instructions, such as return or 
branch), or code fragments that never complete (e.g. calling "exit this process" system call). In other 
words padding is never executed in .text segments. The .init fragments on the other hand 
contain pure code and are concatenated to form a linear stream of machine code. The padding values 
are therefore executed as machine instructions and non-NOP padding is bound to have undesired side 
effects such as segmentation violation. 


Andy Polyakov has prepared a patch of sorts to address this issue 
(http://www.openssl.org/~appro/values.c). This “patch”, a single file which is both a shell script and 
aC source file, modifies the Solaris gcc development environment only, not the OpenSSL code. On 
Solaris linking with 1ibc requires linking with an object module which instantiates the 
_lib_version constant. This object module is commonly provided by Sun and is linked first prior 
to crtbegin.o. The patch procedure strategically places a replacement module” on the gcc library 
search path. But in addition to _1ib_version the replacement module contains an . init snippet, 
which simply checks if the value following the snippet code is zero (i.e., the troublesome padding) or 
not and conditionally skips over or executes it. 


The alignment of this replacement module .init fragment and the OpenSSL .init fragments is chosen 
carefully to work with both older and newer versions of gcc. If OpenSSL .init fragments were not 
aligned the way they are, then padding following the last one would cause the problem with older 
versions of gcc. Lack of replacement module padding preceding the first OpenSSL .init fragment 
would cause the problem with newer versions of gcc. The patch addresses both older and newer gcc 
versions. 


Note the end-user does not need to patch anything to run the linked application. Replacement 
modules are linked statically (just like the original ones) into either application or shared object code. 


The values . c patch actually installs several files with names of the form values—X?.0. Which of these files is 
referenced depended on the compiler options. For example, “cc -Xc ...” references values—Xc.o, “, “cc 
-Xt ...” references values—Xt .o, and gcc references values-Xc.o if -ansi is specified and values- 
Xa . o otherwise. 
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The gcc installation modifications can be reverted by removing the files “values-x*.o” from the 
directory containing 1ibgcc.a. The location of that directory can be obtained by executing “gcc 
-print-libgcc-file-name . 
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Appendix G Restrictions on the Export of Cryptography 


Government restrictions and regulations on the use, acquisition, and distribution of cryptographic 
products are a matter of concern for some potential users. 


In the United States the current export regulations appear to more or less leave open source alone, 
except for a reporting requirement to the Bureau of Industry and Security (BIS) of the U.S. 


Department of Commerce; see http://bxa.doc.gov/Encryption/pubavailencsourcecodenofify.html. 


When in doubt consultation with legal experts would be appropriate. The E-mail message the 
primary author of this document sent was: 


To: crypt@bis.doc.gov, enc@nsa.gov, web_site@bis.doc.gov 
Subject: TSU NOTIFICATION 


SUBMISSION TYPE: TSU 

SUBMITTED BY: Steve Marquess 
SUBMITTED FOR: Veridical Systems, Inc. 
POINT OF CONTACT: Steve Marquess 
PHONE and/or FAX: 301-831-8447 
MANUFACTURER: N/A 

PRODUCT NAME/MODEL #: OpenSSL 

ECCN: 5D002 


NOTIFICATION: http://cvs.openssl.org/dir 


Employee(s) of Veridical Systems, Inc. are participating in the 
development of the freely available open source OpenSSL product by 
providing feedback on new releases, by requesting new features, and by 
correspondence either to the developer and user mailing lists or 
directly with the core developers. This correspondence may include 
suggested source code fragments or patches. All versions of any such 
contributions incorporated in any of the OpenSSL software will be 
publicly accessible at http://cvs.openssl.org/dir. 


No response was received (or expected). 


Other links of interest: 


http://bxa.doc.gov/Encryption/ChecklistInstr.htm 
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